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(57) An authentication session key is generated on 
a trusted machine based upon an identifier of its CPU, 
hardware configuration, and a timestamp. The trusting 
machine retrieves this same information about the trust- 
ed machine, and then generates session locks for the 
machine which are valid for a predetermined time inter- 
val, if the incoming session key matches one of the ses- 
sion locks, and the incoming session key is not on the 
list of used keys, the session key is appended to a list 
of keys which will no longer thereafter be valid, and ac- 
cess is then granted, thereby employing single-use 
keys. Because the locks and keys are also generated 
during a timestamp, a user may request service from 
the same machine multiple times by waiting no more 
than a predetermined time between requests, or front 
ends to the masquerade protection tools could be writ- 
ten that re-try until successful. Because the keys gen- 
erated are specific to the hardware characteristics of the 
trusted machine upon which they are generated, at- 
tempts to gain access from an imposter machine will 
generate unusable session keys. 
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Description 

Technical Field 

This invention relates to security in computer network systems and, more particularly, to systems and methods for 
authenticating users and their machines so as to prevent masquerading attacks. 

Background of the Invention 



Recent developments in computer science are now more effectively exploiting the potential power afforded by 
computer networks. More particularly, developments in distributed computing, m u It i -processor technology, remote file 
system access, and the like, have significantly increased the productivity, utility and power of such networks. Recently, 
powerful tools have been developed utilizing the processing power of multiple machines to effect these improvements. 
For example, systems based on the UNIX (trademark of the Novell Corporation) operating system conventionally pro- 
vide for commands such as rlogin, rsh, and mount of a remote file system which, respectively, permit a user at one 
machine to log onto a remote machine, to remotely execute commands and mount a remote file system located on 
one or more machines physically separated on the network from the machine the particular user is employing. 

However, in such systems wherein a user may have access to multiple machines, serious problems have arisen 
with respect to security and authorizing use. One approach to addressing these problems is to simply provide a user 
with specific passwords associated with each machine on the network for which the user desires access. However, 
forcing a user to always type a password for each machine may become unworkable and unacceptable in many cases. 
This is particularly true if, for instance, a user needs to distribute a task among several machines (which is becoming 
fairly commonplace in modern day computer technology). 

Historically, this problem has been alleviated to some degree with various techniques having their own limitations, 
such as providing a trusting machine with an rhosts file, in the UNIX environment, for example, which includes the 
user name and hostname of the trusted user employing the machine to be trusted. 

Using such techniques as rlogin, rsh, and mount of a remote file system provides powerful functionality but, un- 
fortunately, also renders such network system vulnerable to attacks on the system employing a method known as 
"masquerading". Masquerading occurs when the attacker brings a machine onto a network with a network or internet 
protocol address of a "trusted" machine. Then, by becoming a certain user on the attacking machine known to the 
receiving machine, the attacker may thereby gain access to the "trusting" machine by masquerading as this user. The 
trusting machine thereby believes that the attacker is requesting access from the trusted user on a trusted machine. 

Accordingly, from the foregoing, it will be readily apparent that a serious problem was presented in finding a way 
for one machine on a network to verify that any request from a trusted machine in fact was really originating from the 
trusted machine and that the request was thus not being provided by a clever imposter. 

Solving these serious security problems has commanded a great of deal of attention in the computer field due to 
the potential for great damage both in terms of property value and safety should these networks be compromised. It 
is unfortunately becoming almost commonplace to hear reports of networks being broken into at great loss of security 
privacy, data integrity and the like, and when such systems relate to international banking, national security, flight 
control, medical records, and so on, the seriousness of the problem can be readily appreciated. 

Thus, the industry has a long history of developing techniques involving keys, such as those employing timestamps, 
encryption, and various forms of authentication in an effort to render networks more immune to attacks, but nevertheless 
regrettably the problem remains. As but one example representative of the extensive amount of work being done on 
the authentication problem, a security system known as Kerberos has been developed principally at the Massachusetts 
Institute of Technology. However, even such a sophisticated system is vulnerable to network "sniffers 1 * which may 
intercept a key or password, and then be utilized by the unauthorized interloper to gain access to the network. 

As to the technique of providing keys, as general background this technology may be seen represented in U.S. 
Patent 5,136,643 which utilizes public/private key pair technology to authenticate timestamps. Similarly, U.S. Patent 
5,313,521 employs public/private key pair technology to safely exchange standard private keys. In like manner, U.S. 
Patent 5,371 ,794 also utilizes this public/private key pair technology to encrypt/decrypt wireless communications. How- 
ever, for various reasons, all of these systems are still nevertheless subject to several weaknesses to be hereinafter 
detailed. 

Also by way of background, one other approach in the art has been to simply, in brute force, encrypt the data being 
transmitted back and forth between stations. Representative examples of this technology include U.S. Patent 5,31 9,710 
on encryption, decryption of transmitted transaction data, and U.S. Patent 5,349,642 which authenticates a message 
by encrypting it at the sender and decrypting at the receiver One obvious disadvantage of such systems is that the 
actual data itself must be encrypted and decrypted, with associated delays in processing, and the like. 

Yet another species of solutions seeking to render networks more secure involves the concept of timestamps. This 
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technique may be seen represented in U.S. Patent 5.351.293. which utilizes a timestamp for initial validation, where- 
upon again the data is then encrypted. U.S. Patent 5.351,293 also uses the concept in metering transmission of en- 
crypted data but does not approach the problem in the manner of the present invention in addressing initial authenti- 
cation. One perhaps more relevant approach in the prior art may be seen disclosed in U.S. Patent 5.351.295 which 

5 does attempt to prevent some form of impersonation or masquerading and replay attacks. However, as will become 
readily apparent from the detailed disclosure of the invention, this system does not protect one neighbor from another. 
In other words, one trusted neighboring user may have all the information necessary to impersonate another trusted 
neighbor user. This is so because no secret key is provided for a specific user/machine which includes specific hardware 
configuration data for such authentication. Moreover, the system disclosed in U.S. Patent 5,351.295, as noted, does 

10 not prevent replay attacks in a situation where a perpetrator may manipulate the system clock to thereby thwart times- 
tamping. 



Summary of the Invention 

is The present invention provides an improved system and method for preventing masquerading in a computerized 

network. 

In a first aspect the invention provides a method for providing masquerade protection in a computer network, 
comprising: 

20 generating a session key with a first machine as a function of a timestamp and one or more hardware characteristics 

unique to said first machine; 

transmitting said session key over said network from said first machine to said second machine; 
generating a plurality of locks with said second machine as a function of said timestamp and said hardware char- 
acteristics; 

25 testing with said second machine whether said session key matches one of said plurality of locks; and 

granting access from said first machine to said second machine when said session key matches said one of said 
plurality of locks. 

In a second aspect, the invention provides an apparatus for providing masquerade protection in a computer net- 
30 work, comprising: 

means for generating a session key with a first machine as a function of a timestamp and one or more hardware 
characteristics unique to said first machine; 

means for transmitting said session key over said network from said first machine to said second machine; 
35 means for generating a plurality of locks with said second machine as a function of said timestamp and said 

hardware characteristics; 

means for testing with said second machine whether said session key matches one of said plurality of locks; and 
means for granting access from said first machine to said second machine when said session key matches said 
one of said plurality of locks. 

40 

The present invention preferably provides for additional authentication employing specific data in the authentication 
scheme related to the particular machine and time. 

The present invention preferably provides for such improved network security without necessity to employ data 
encryption. 

45 The present invention preferably provides for masquerade protection which renders exhaustive system attacks 

impractical. 

The invention preferably provides for improved network security which is immune to replay attacks by a system 
administrator such as those wherein a system clock is manipulated. 

The present invention preferably provides a system to protect against computer network masquerading attacks 
so which accounts for lack of perfect synchronization of system clocks, and for machines being located in differing time 
zones. 

The invention preferably provides for masquerade protection against imposters inside a subnet attempting to ac- 
cess machines within the subnet by utilizing the same network or internet protocol address as a legitimate machine. 

According to a preferred embodiment, the invention provides for such masquerade protection while at the same 
55 time allowing for access to the network by intermediate machines using conventional multiple access technology such 
as rlogin, rsh, and mount of a remote file system. 

In accordance with the teachings of the invention, an additional authentication step is provided beyond the normal 
conventional hostname or network address of the incoming machine and the user name of that machine. In a particular 
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embodiment, this additional authentication, transmitted by altered versions of rsh, rlogin and mount, is received and 
verified by alternate versions of rshd, fogr/n and rpc.mountdon the trusting machine providing the service. The additional 
authentication, herein referred to as a "session key", is generated on the trusted machine based upon a unique identifier 
of its CPU, hardware configuration, and a timestamp. The trusting machine receiving the request checks a table to 

5 determine the hardware information of the incoming machine (e.g., CPU-id, hardware configuration, etc.), and then 
generates session locks for that particular machine only. In the preferred embodiment, these locks are valid for a 
predetermined time interval such as from time (-5 minutes) to time (+5 minutes). 

If the incoming session key matches one of the session locks, the session key is then appended to a list of keys 
which will no longer thereafter be valid, and access is granted. This system thereby employs, as an important feature 

10 of the preferred embodiment of the invention, the concept of single use keys. Because the locks and keys are also 
generated during a timestamp, a user may request service from the same machine multiple times, by waiting no more 
than a predetermined time such as 60 seconds in the preferred embodiment, between requests, ft is a further important 
feature of the invention that any attempt to gain access from an imposter machine will generate completely unusable 
session keys, as keys are generated partly as a function of information specific to the particular hardware characteristics 

15 of the machine upon which the keys are generated. 

Brief Description of the Drawings 

The invention as well as a preferred mode of use, further objectives and advantages thereof, will best be understood 
20 by reference to the following detailed description of an illustrative embodiment when read in conjunction with the ac- 
companying figures, wherein: 

Fig. 1 is a pictorial representation of a data processing system which may be utilized to implement the system and 
method of the present invention. 
25 Fig. 2A depicts a block diagram of a local area network from the data processing system illustrated in Fig. 1 for 

implementing the system and method of the present invention, and which may benefit from the masquerade pro- 
tection technique of the present invention; Fig. 2B depicts a block diagram of a mainframe computer from Fig. 1 
for implementing the system and method of the present invention; 

Fig. 3A is a flow diagram illustrating the system and method of the invention, and more particularly, illustrating a 
30 specific example of a user on a trusted machine remotely logging into a secured machine with rlogin; 

Fig. 3B is a continuation of the drawing of Fig. 3A; 

Fig. 4 is a block diagram illustrating the process by which the SECURE machine obtains a session key and either 
grants or denies access to the TRUSTED machine; 

Fig. 5 is a conceptual illustration of principles of the invention particularly relating to the pseudo-random number 
35 generation and its use in the SECURE and TRUSTED machines for a complexity of 1; 

Fig. 6 is another drawing illustrating concepts of the invention including the manner of generating the pseudo- 
random output stream from differing hardware-dependent seed values, and the use of such stream in generating 
multiple session keys; 

Fig. 7 is a flow diagram illustrating generation of seeds by the TRUSTED machine; 
to Fig. 8 is a flow diagram illustrating use of a plurality of locks from corresponding multiple seeds. 

Detailed Description of the Preferred Embodiment 

In order to understand application of the invention to computer networks, a description will first be provided of a 
45 representative such computer network wherein the invention may be advantageously employed to effect the desired 
protection against masquerade attacks on the security of the network. It will be readily appreciated that the invention 
admits to applicability to any embodiment of a computer network and thus is not intended to be so limited to the particular 
illustrative network hereinafter described. 

With reference now to the figures, and in particular with reference to Fig. 1 . there is depicted a pictorial represen- 
so. tation of a data processing system 8 which may be utilized to implement a method and system of the present invention. 
As may be seen, data processing system 8 may include a plurality of networks, such as local area networks (LAN) 10 
and 32, each of which preferably includes a plurality of individual computers 1 2, 1 2a- 1 2c, 30, 31 , 33 and 35. (Hereafter, 
when discussing a computer in network 32, a computer 30 will be arbitrarily referenced, although the discussion could 
relate to any of the computers in network 32). Computers 1 2 and 30 may be implemented utilizing any suitable computer 
55 such as the IBM Personal System/2 (also called a "PS/2") computer or an IBM RISC SYSTEM/6000 computer, both 
product of International Business Machines corporation, located in Armonk, New York. "RISC SYSTEM/6000" is a 
trademark of International Business Machines Corporation, "Personal System/2" and "PS/2" are registered trademarks 
of International Business Machines Corporation. Of course, those skilled in the art will appreciate that a plurality of 
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intelligent work stations (IWS) coupled to a host processor may be utilized for each such network. 

As is common in such data processing systems, each individual computer may be coupled to a storage device 1 4 
and/or a printer/output device 1 6. One or more such storage devices 14 may be utilized, in accordance with the method 
of the present invention, to store objects, such as documents, resource objects, or executable code, which may be 

5 periodically accessed by any user within data processing system 8. In a manner welt known in the prior art, each such 
object stored within a storage device 1 4 may be freely interchanged throughout data processing system 8 by transferring 
an object to a user at an individual computer 12 or 30, for example. 

Still referring to Fig. 1 , it may be seen that data processing system 8 also may include multiple mainframe com- 
puters, such as mainframe computer 18, which may be preferably coupled to LAN 10 by means of communications 

10 link 22. Mainframe computer 1 8 may be implemented utilizing an Enterprise Systems Architecture/370 (also called an 
"ESA/370") or an Enterprise Systems Architecture/390 (also called an a ESA/390 H ) computer available from IBM. De- 
pending on the application a mid-range computer, such as an Application System/400 (also called an "AS/400"), may 
be employed. "Enterprise Systems Architecture /370", "ESA/370", "Enterprise Systems Architecture/370", and "ESA/ 
390" are trademarks of IBM; "Application System MOO" and "AS/400" are registered trademarks of IBM; "Application 

is System/400" and "AS^O" are registered trademarks of IBM. Mainframe computer 18 also may be coupled to a storage 
device 20 which may serve as remote storage for LAN 10. Similarly, LAN 10 may be coupled via communications link 
24 through a subsystem control unit/communications controller 26 and communications link 34 to a gateway server 
28. Gateway server 28 is preferably an individual computer or IWS which serves to link LAN 32 to LAN 10. 

As discussed above with respect to LAN 32 and LAN 10, objects may be stored within storage device 20 and 

20 controlled by mainframe computer 1 8, as Resource Manager or File System Manager for the stored objects. Of course, 
those skilled in the art will appreciate that mainframe computer 18 may be located a great geographic distance from 
LAN 10 and similarly LAN 1 0 may be located a substantial distance from LAN 32. For example, LAN 32 may be located 
in California while LAN 10 may be located within Texas and mainframe computer 18 may be located in New York. 
A preferred embodiment of the present invention may be incorporated within various computers depicted within 

25 data processing system 8. Referring now to Fig. 2A, a block diagram of LAN 10 is depicted for implementing a method 
and system of the present invention. Server 12 communicates with computer 12a-12c over communications channel 
34. LAN 10 is depicted in a token ring geometry, however, other geometries are possible. Server 12 may be a conven- 
tional computer, such as an IBM PS/2 or AS/400 system programmed to practice this invention. Server 12 includes a 
central processing unit (CPU) 35, a memory 38, and a network adapter 40. Network adapter 40 is utilized for formatting 

30 outgoing transmissions and for deformatting incoming transmissions. Server 12 also includes a hard drive unit 42 for 
storing various objects, such as data files or executable code. Objects may be accessed by one or more users, wherein 
an object may be transferred to computer memory 38 over data bus 44. A number of objects may exist within memory 
38. An operating system and local are network server 46 are represented as one object within memory 38. 

Various users may access objects by sending a request to a file system which is conventionally resident on hard 

35 drive 42 in server 1 2 utilizing computers 1 2a-1 2c. A "file system" is a collection of files and file management structures 
that may be located on the physical or logical mass storage device (or even memory 38). Computer 12b is a typical 
example. Computer 12b operates as a personal work station communicating with server 12. Schematically, computer 
1 2b is substantially similar to server 1 2, and includes a network adapter 60, a display adapter 62, a hard drive unit 64, 
a central processing unit (CPU) 66, and addressable memory 68. Components of computer 12b transfer data over 

40 data bus 70. CPU 66 directly controls input peripherals 72, which may include a keyboard and a mouse. Display adapter 
62 drives display device 74. Memory 68 includes part or all of an operating system 73 which also is conventionally 
resident in the mass storage device such as hard drive 64. Memory 68 also includes object 76, which was supplied by 
computer 12 in response to a request to computer 12. 

Referring now to Fig. 2B, a block diagram of mainframe computer 18 is depicted in accordance with a preferred 

45 embodiment of the present invention. Mainframe computer 1 8 is a single computer system running multiple processes, 
such as an IBM ESA/370 or ESA/390 attached to multiple nonprogrammable work stations (NWS) 100a-100n. Main- 
frame computer 18 includes a hard drive unit 102, CPU 104, input/output (I/O) processor 106 for communicating with 
nonprogrammable work stations 100a-100n, network adapter 108, and memory 110. Hard drive unit 102 may store 
objects. Each nonprogrammable work station may access an object within memory 110 or hard drive unit 102. For 

so example, nonprogrammable work station 100a would access object 112a, nonprogrammable work station 100b would 
access object 1 1 2b, and nonprogrammable work station 1 0On would access object 11 2n in accordance with a preferred 
embodiment of the present invention. 

An "object" is any real resource that has an ACL associated with it. In the depicted example, an "object" corresponds 
to a subdirectory or a file in a hierarchical file system. The "attributes" of an object are represented in an access control 

55 list (ACL). A "container object* is an entity that may contain zero or more objects or container objects. In the depicted 
example, a container corresponds to a directory in a hierarchical file system. 

Now that a general background of computer networks has been provided in which the invention may be advanta- 
geously employed, an overall description of a particular embodiment of the invention will be provided. This will be 
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followed by a more particular description of the invention by way of the flow diagram of Figs. 3A-3B, illustrating a 
specific instance of the masquerade protection scheme. This, in turn, will be followed by a more detailed description 
of the unique hardware-specific information employed as an important part of the invention in ensuring against ex- 
haustive attacks. 

5 One characteristic of machines running in a typical computer network is that it is possible to generate a relatively 

unique indicator associated with the particular machine which, in the embodiment described herein, includes an iden- 
tification of the machine's CPU and other hardware. It will be appreciated that it is a matter of choice as to how detailed 
and unique this machine-specific data is, and the invention is not intended to be limited to the particular method of 
generating a machine-specific indicator as herein set forth. 

10 However, in the embodiment disclosed, it is assumed that the machine is running in a UNIX environment and will 

have a CPU-id and a hardware configuration unique to that particular machine. In accordance with conventional UNIX, 
combinations of commands may be issued such as "uname -m I cut -c3-8" which, upon execution, will reveal the 
particular CPU-id number of the machine on which the command is executed. In like manner, a combination of other 
well known commands in the AIX operating system may be issued "Iscfg -v I sum -r" which will, upon execution, yield 

15 two numbers, the first of which will be the machine's hardware configuration checksum. This checksum will be a number 
indicative of various hardware aspects of the particular machine for which the command is executed, such as the 
adapter cards installed, the amount and type of DASD, etc. and will thus provide a "fingerprint" specific to the machine. 
It will be appreciated that different operating systems may have other implementations of this functionality (such as 
"qconfig") with respect to dos) which will facilitate arriving at such a machine-specific fingerprint. Although the particular 

20 machine characteristics accounted for may differ and be a matter of choice, as desired, the key point is that a number 
is generated specific to the hardware of the machine generating the number. In the implementation this is accomplished 
by use of the CPU-id and hardware checksum. While these numbers, and therefore the resultant product may not 
necessarily be absolutely unique to the machine from which they are derived (e.g., given enough machines, another 
machine may yield on identical product however unlikely, the point is that a number specific to a particular machine 

25 may be generated to any desird degree of "uniqueness" to that machine. This number, in turn and as will be seen, will 
have a bearing on the degree of masquerade protection provided. Thus the implementer of the invention may control 
the desired level of protection by the manner in which the numbers are generated.e.g., how "unique" they are to one 
and only one machine. 

In accordance with the invention, a session key to be sent from a trusted machine to a trusting or "secure" machine 
30 js thereby formed by the trusted machine being utilized by the user, such session key being formulated in several steps 
which include this hardware-specific number. 

First, a function "srandom((CPUID)*(Hardware Configuration Checksum))" is called to seed the machine's random 
number generator with hardware-specific information. 

Next, at the user's machine, a next function "gettimeofday" is called to set a value for T' seconds (tsecs) seconds 
35 past an arbitrarily chosen time such as midnight, January t , 1 970. It will be noted that more genericaily speaking, this 
function will simply return a value which can be associated with the particular time at which the command is issued. 

Next, a function "timestamp" is then called which will set a parameter to "(tsecs/key_change_A) + 
arbitrary_constant M , where "key_change_A* is the number of seconds desired between key changes, and 
"arbitrary_constant" is an arbitrary constant selected to be the same and known both on the sending trusted and re- 
40 ceiving trusting machines. 

Next, a "session.key" parameter is set to "randomO* which, after looping "timestamp" times, will return a random 
number. In the implementation being described, this number will range from 1 to 2,147,483,647, although again it will 
be readily appreciated that the range of this random number may be preselected to any desired number. In accordance 
with the preferred embodiment thus, if the timestamp is 57 million, then the trusted machine will seed its random number 
45 generator with hardware information unique to itself, and set the session key to the 57 millionth random number thereby 
calculated by this step. It is important to note that this is a one-way hash function, inasmuch as it is impossible to 
- calculate the seed from the result of a random function. 

It is helpful at this point in understanding the entire concept of the invention to think of it in physical terms as each 
trusted machine having its own unique lock wheel where only a preselected number of locks out of the aforementioned 
50 possibility of 2,147,483,647 are valid at any one given time, where the wheel rotates a lock in and a lock out of the 
* valid range every "keychange delta" seconds, and wherein the wheel is totally different tor each different machine. In 
the preferred embodiment under discussion, only 11 locks out of the 2,147,483,647 are valid and the wheel will rotate 
the lock into and out of the valid range every 60 seconds, although, in like manner to the magnitude of the random 
number, these values may be selected as desired and for purposes to be hereinafter described. 
55 The lock wheel, with its 2,1 47,483,647 locks (each of which is different for every trusted machine) rotates counter- 

clockwise every 60 seconds, bringing one new lock into the valid range of 1 1 locks, and moving one old lock out of the 
valid range of 11 locks. 

It will be recalled that because of the foregoing mechanism, only a predetermined number of locks (such as 11 in 
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the embodiment) will be valid for any particular time, and the wheel will hold enough locks for a substantial period of 
time (4,083 years in the embodiment under discussion). 

The trusting machine having masquerade protection of the present invention will then obtain the hardware infor- 
mation for the incoming trusted machine from a lookup table, which has previously stored in it, this data (including the 
CPU-id, hardware configuration checksum, or any other number as desired uniquely associated with the particular 
trusted machine, and further including a "key change delta" seconds value and an arbitrary constant). The trusting 
machine will then formulate a predetermined number of locks for that incoming trusted machine only. In the embodiment 
under discussion, this predetermined number will be 1 1 locks - one for each minute from 5 minutes prior to the present 
to 5 minutes into the future. If the incoming session key has not yet been used as determined by the trusting machine, 
and if it fits one of the previously described 11 locks for that incoming machine only, then this incoming key is added 
to a "used key" list, and access is granted to the trusted machine. It will be noted that the two machines' clocks must 
be synchronized to be identical to within the predetermined time range, e.g., in the implementation being described 
within +- 5 minutes. 

From the foregoing high level description, many advantages of the present invention may be readily apparent over 
the approaches taken by the prior art. First, the solution to the problem provided by the invention is based upon a 
function unique to the trusting and trusted machines - such function being based upon the trusted machines CPLMd, 
and hardware configuration, and is further based upon time. This approach makes it possible to change keys by simply 
changing hardware configurations slightly (for example if it is thought that the hardware-specific data has been com- 
promised). Yet, it is nearly impossible for an imposter attacker to generate another machine with the same hardware 
characteristics. This also makes an exhaustive attack impractical, as every new attempt would require some change 
to the hardware configuration. Moreover, this single-use key concept (implemented by adding a key to a used key list 
precluding its subsequent use beyond the predetermined time interval) protects the system against an attacker em- 
ploying a network sniffer, Even though the attacker may be able to surreptitiously view the session key as a user is 
granted service, the session key thereby seen by the attacker has already been rendered useless on the machine 
granting service. 

Still further advantages of the present system over those provided by prior art may be appreciated. The invention 
addresses the problem of vulnerability to an imposter on the same subnet using the same address as a truly trusted 
machine. Prior art solutions typically have only protected against such imposters outside a subnet trying to appear to 
be a machine within the subnet. 

Yet another problem addressed by the invention is that potentially, with respect to authorization schemes, tools 
utilized to generate the keys may be reverse engineered to reveal the operative algorithm. In such a case, an attacker 
may write software to exhaustively search all keys without needing to change the hardware configuration between 
attempts which would otherwise be necessary if such a system were devised which brought unique hardware into play. 
The keys generated by the present invention are based also partly upon time of day, such that no key is valid longer 
than a predetermined time (such as 10 minutes in the embodiment herein described). It will be further readily apparent 
that trying all keys (over 2 billion in the implementation) would require someone to try over 3 million keys per second, 
as any slower attack rate simply could not keep up with the key changes. Thus, by invalidating keys after a predeter- 
mined period and adding keys to a "used key list", this prevents an imposter from attempting to intercept a key or 
password off the network and immediately use it, as keys are flagged as no longer valid to prevent someone from 
"walking in" behind a bona fide user. 

In the background of the invention, conventional application of public/private key pair technology was discussed 
wherein safe exchange of standard private keys is made to authenticate timestamps, safely exchanged standard private 
keys, and the like. However, although the present invention does utilize timestamps, they are not employed in the 
conventional sense, nor does the invention use public/private key pairs. On the contrary, the invention utilizes a user- 
configurable method of using a timestamp as an encryption key which is only used to encrypt an authentication token. 
Some of the keys are configurable, and some depend uniquely upon the hardware. 

Still further, as previously set forth in the background of the invention, conventional encryption/decryption technol- 
ogy is inapposite to the invention which does not encrypt data but rather authenticates a sender and does not transmit 
encrypted data of necessity after the initial authentication. The present invention provides for a unique secret key and 
uses hardware configuration for authentication, thereby preventing replay attacks in a situation where a perpetrator 
can manipulate a system clock. Once a key is utilized, it is added to a "never use again" list such that even if a clock 
is in fact manipulated, a duplicate key is always disallowed such that the system is immune to replay attacks by those 
who might manipulate the system clock. Unlike prior systems, the present invention uses its methods at the endpoints 
of an n-machine network path employing unique key spaces (a key space of 10 to the 45th power in the disclosed 
embodiment), Moreover the invention can be utilized even if an intermediate machine does not utilize the system 
without crippling the intermediate machine's use in the network. 

Still further, by providing for the predetermined time space wherein a key may be employed, the invention accounts 
for different computers on the network being in different time zones or not synched to precisely the same time. 
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Turning now to Fig. 3A, from the foregoing it will be understood that the masquerade protection scheme of the 
present invention operates by the conditional creation and verification of identification tokens added to the conventional 
rlogin, rsh, and mount interfaces. In Figs. 3A and 3B, an example of the steps in using the invention are shown for an 
rtogin. In the example, it will be assumed that a user on a trusted machine such as machine 12B of Fig. 1 desires to 

s remotely log into a secure or trusting machine such as machine 12A in Fig. 1 wherein the masquerade protection of 
the invention is implemented with respect to the machines 12A and 12B. For simplicity, with respect to Figs. 3A-3B, 
this trusted machine will simply be referred to as TRUSTED : and the secure machine as SECURE. First, as indicated 
at block 200 and as just noted, a user on TRUSTED is desirous of remotely logging into SECURE. Accordingly, the 
user would first type "rlogin SECURE". Note that this is a conventional login command which would be employed 

10 regardless of whether the user was logging into a machine with masquerade protection or not, thereby indicating the 
invention may be implemented in systems including machines wherein the masquerade protection is not implemented 
or required. 

Executing the command, 200 : thereafter will invoke a modified version of rlogin which will check a directory such 
as /etc/hosts. SECURE, thereby either executing a check to see if SECURE has masquerade protection tools which 
15 will be ready to validate a session key. If the SECURE machine is not listed in the directory, this indicates that a normal 
or conventional rlogin procedure is required, 204. Thus, the standard (e.g., unmodified) rlogin command is executed, 
232. 

Assuming secure is listed within the directory, an identification token, e.g., session key, will be generated and sent, 
206, as follows. A checksum will be run on TRUSTED's hardware configuration which will then be multiplied by TRUST- 

20 ED's CPU-id to obtain a seed, which is then utilized to seed a random number generator, 208-213. More particularly, 
a product will be formed from the TRUSTED CPU-id multiplied by the hardware configuration checksum, 208. This 
product should be within the seed space inasmuch as it will be utilized to seed the random() generator. However, it will 
be appreciated that in some systems it is possible that this product would exceed the seed space if the maximum CPU- 
id and/or hardware checksum were too large. Accordingly, a process must be provided for devising this and ensuring 

25 the product is in fact within the seed space. Accordingly per block 211 , a check is made to determine if the product of 
block 208 is greater than the seed space. If not (which is the more probably result), this product becomes the seed 
which is then utilized to seed the random number generator, 213. If, on the other hand, the product of block 208 is 
greater than the seed space, in a preferred embodiment, the seed space is subtracted from this product to form a new 
product, 215, and the result is looped back to the decision block 211 to determine if this new product is greater than 

30 the seed space. The immediately preceding process 211-213 is iterated until at some point the product is not greater 
than the seed space, in which case, as previously described, one of these new products becomes the seed utilized to 
seed the random number generator, 21 3. Next, a timestamp value will be determined. This may be effected by calling 
a gettimeofdayQ or similar function. This will produce a time corresponding to the time the routine was called (which 
conventionally is reckoned in the number of seconds subsequent to January 1 , 1 970). This value is divided by a constant 

35 GCON and then another constant ACON is added to this result to obtain the desired timestamp value, 210. If will be 
noted that this modified version of rlogin, which is executable by any user but only readable by a user with root authority, 
will preferably have compiled within it these GCON and ACON constants, as well as a COMPLEXITY constant for 
purposes which will hereinafter be made clear, all such constants being selected by the system administrator of TRUST- 
ED. 

40 Next, as shown by decision block 212, a determination will be made if the preselected complexity constant is equal 

to or greater than 2. At this point it will be sufficient merely to note that this COMPLEXITY constant is selected to 
indicate the desired extensiveness of the masquerade protection. If a higher complexity number is selected, as will be 
hereinafter described in greater detail, this will effectively cause an iterative process to transpire, generating key frag- 
ments related to the particular COMPLEXITY constant selected. These key fragments will be concatenated to generate 

45 a session key. It will thus be appreciated that essentially selecting a higher complexity number will result in a larger 
session key with more numerals, thereby making it more difficult to attack a system and generate such a session key. 
If it is determined that the COMPLEXITY constant is equal to 1 , as indicated by the branching from the decision block 
212 to the right, the pseudo random number generator function random() will be called repeatedly. Specifically, the 
random function will be called (timestamp - 1) times, e.g., the value of (timestamp determined at step 210-1) times. 

50 At the last such call of random, the result thereof will be defined as the session key, 216. At step 230, the TERM 
environment will then be prepended with this session key and a colon (step 230) after which the standard rlogin com- 
mand will be- executed. 232 (Fig. 3B). 

Returning back to block 212 of Fig. 3A, if it is determined that the COMPLEXITY constant is equal to or greater 
than 2, again the random() function will be called, but this time will be called the timestamp value (determined at block 

55 21 0) - 2 number of times, and the next COMPLEXITY results will then be collected to be used as seeds to be hereinafter 
described, 214. Next, shown as step 218, a session key will be initialized to an empty string of characters, 218. 

Continuing with Fig. 3B, with respect to every seed generated at block 214, as shown at block 220, the following 
steps 222-228 will be executed. First, a pseudo random number generator will be seeded with the current seed, 222. 
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The timestamp value (block 210) will then be divided by 10,000 and the remainder taken, 224. The random() function 
will then be called by a number of times equal to this remainder determined at block 224, and then the distribution of 
the last result will be normalized by dividing by 2.147483648 in order to form a session key fragment, 226. As shown 
at step 228, this key fragment will then be appended to the desired session key, whereupon the previously noted steps 

5 222-228 wilt be repeated if there are more seeds to handle. 

Next, the TERM environment will be prepended with the resultant session key (comprised of the previously gen- 
erated key fragments) and a colon (step 230) whereupon the standard rlogin command will be executed, 232. 

Turning now to Fig. 4, the SECURE machine will obtain the incoming session key from the incoming TERM variable, 
whereupon SECURE will then remove it to restore the TERM variable to a valid value, 234. In accordance with the 

10 invention, a modified version of the login function will be present on the SECURE machine. This login will employ 
conventional netstat commands in order to determine the incoming Internet Protocol (IP) address, 236 of the machine 
making the most recent (current) incoming connection, login will also then refer to a lookup table in order to determine 
specific values for the previously mentioned GCON, ACON, and COMPLEXITY constants, 238, all such constants 
being specific to the machine with that particular I P address. It will appreciated that these constant values will previously 

is have been communicated by some secure method between the trusted and secure machine owners. This previous 
step is shown at block 238. 

Next, SECURE will determine from the lookup table if the incoming machine's IP address is in the table, 240. If it 
is not, SECURE denies access, 242. If, on the other hand, the IP address is in the table, then SECURE executes steps 
210-228 previously described for each of 11 timestamp values from -5 minutes to +5 minutes to generate what the 

20 session keys should be for the incoming machine from -5 minutes to +5 minutes, 244. Next, a determination is made 
by SECURE as to whether the incoming session key has either already been used before or is not one of the session 
keys it should be (as determined at step 244), in which case in either event if the key has been used or is not what is 
expected, SECURE again denies access, 248. On the other hand, if the session key has not already been utilized and 
is one of the expected keys, this session key will be added to the list of keys no longer usable and access will thereby 

25 be granted, 250. 

Now that a high level description of the invention with reference to Figs. 3A, 3B, and 4 has been provided, several 
more detailed points should be made with respect to certain of the steps detailed therein. First, with respect to step 
200-204 Figs. 3A-3B, it will be appreciated that this feature of employing the same login command for machines either 
with or without masquerade protection is a valuable feature in essentially providing a transparent user interface ac- 

30 commodating a heterogeneous network of both secure and unsecured machines. 

With respect to these blocks 200-204, there is a significant benefit to providing a special version of rlogin which 
checks to see if the SECURE machine is in fact a SECURE machine. It may not be apparent that this facility protects 
against what is known in the art as "black box" attacks, where the attacker seeks to gain access by sending identification 
tokens to his or her own machine for analysis or interception. 

35 Regarding block 208 : it should be noted that while a specific form of checksum has been disclosed, the invention 

is not intended to be so limited. On the contrary, this step may be modified to work on any hardware and generically 
is simply providing information unique to the particular trusted machine from which a user is seeking to log in. However, 
depending upon the degree of security desired, the extent of this hardware-specific information is a matter of prudent 
engineering choice, and the checksum range could be expanded to any input space. 

40 Regarding step 210 in obtaining a value for timestamp, it was noted that the special version of rlogin has precom- 

piled with it GCON, ACON, and COMPLEXITY constants. However, it should be noted that the system could easily 
have multiple special versions of login such as rloginl, and rlogin2, each with different such constants. The purpose 
of so doing is in order to prevent the SECURE 1 machine from masquerading as the TRUSTED machine to the SECURE 
2 machine. 

45 Regarding step 226, in the specific implementation disclosed, up to a 45 digit number is created by calling random 

() "remainder" times. Accordingly the distribution of the last result is normalized by dividing by the specified number in 
order for the result to range from 0 to 999,999,999. It will be apparent that this range is however a matter of choice. 
Similarly, with respect to step 224, the constant of 10,000 selected to divide timestamp by is in like manner a matter 
of choice and need not be 10,000. The value is selected simply to avoid performance problems associated with calling 
50 random () by COMPLEXITY x timestamp number of times, although this certainly could be done. 

Finally, with respect to block 230, this step is "customized" in order to get the key through a normal rlogin interface 
(e.g.. one without masquerade protection). $TERM is normally passed from rlogin on the originating machine to riogind 
on the destination machine. For rsh, the key is prepended to the command, and for a mount such as the network file 
system (NFS) mount, the key is prepended to the mount point path. Any network interface which passes and receives 
55 a character string could thus utilize the same concept as disclosed in the specific embodiment. 

Turning to Fig. 5 now, a graphic depiction is provided of the operation of the invention in order to more clearly 
illustrate the fundamental concepts of the invention. 

First, a three dimensional graph is provided, having X, Y and Z coordinates, 250 : 252, 254, respectively. The 
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ordinant will be recognized as a number corresponding to the CPU-id. In a practical implementation the id may have 
a range from 0-999, 0-9999, or even 0-99999 for example, dependent upon the particular hardware and corresponding 
phsyical CPUs on which the invention operates. The abscissa will be recognized as a continuum of numbers corre- 
sponding to the hardware checksum formed by the function tscfg or some appropriate mechanism for generating a 

5 hardware-specific checksum. In the implementation, this checksum ranges from 0-65535. The ranges for the X and Y 
coordinates will be seen to form a rectangular grid 256 comprised of the product of the CPU-id and checksum numbers. 
This product corresponding to the area of the grid 256 will be recognized as creating a universe of different seeds, in 
this case 9999 x 65535 = 655,284,465 seeds, each one represented by one of the grid boxes such as box 266. For 
purposes of this figure, it will be noted that the product of the CPU-id and hardware checksum was chosen to be within 

10 the seed space. Accordingly, in this illustration there was no need to adjust the product in the manner shown with 
respect to steps 211-21 3 of Fig. 3A to ensure that the product magnitude is within the seed space. In a given system, 
with a sufficiently large potential maximum value of the CPU-id and/or checksum number, the resulting number may 
be larger than the seed space in which the case the process of steps 211-21 3 to adjust the product iteratively so as to 
come within the seed space value would be effected. 

15 Continuing with Fig. 5, extending in the Z axis 254 from each of the grid boxes, is a line intended to represent a 

random stream of one-time use pads generated with its respective seed in the grid from which it originates and the 
pseudo random function random(). The distance along one of these lines parallel to the Z axis 254 corresponds to the 
time spent in repeated calls to the random() function as shown by reference numeral 258. This collection of different 
parallel lines in the Z axis shown by bracket 260 will be comprised of individual lines each emanating from a different 

20 one of the grid boxes such as grid box 266, and further representing a stream of numbers generated from a seed in 
the grid 256 uniquely associated with each such line. 

A particular point along one of the lines is shown by a series of circles 264, in this case associated with a particular 
seed 265, and corresponding stream of numbers generated with this seed, represented as line 267. This series of 
circles is blown up in the lower part of the figure and is intended to represent, as shown by reference numeral 264 

25 schematically, the 11 locks previously discussed. 

A table 262 is shown relating to the SECURE machine which is intended to illustrate the basic high level operations 
performed by the secure machine in affording the masquerade protection of the invention. Specifically, as previously 
discussed, the secure machine will first make sure the incoming machine is in its table, shown at the first step '1". 
Next, the SECURE machine shown in table 262 will utilize this table (readable by root only on the machine) to obtain 

30 the previously described GCON, ACON, and seed values from the table, step "2". The SECURE machine next will 
seed the random() function at step "3 W with the values obtained at step 2 and then call the random() function for a 
prescribed number of times. Specifically random() will be called (tv.vsecs/GCON+ACON-5) numbers of times in order 
to move along the pads line 267 up to a value corresponding to the (present-5*GCON). step B 4*. The results from 
calling random 11 times will then be compared in order to construct locks up until the present+5*GCON (step "5"), the 

35 foregoing being shown by the locks 264. As previously pointed out, for each SECURE machine, multiple rlogins may 
be provided if needed in order to ensure that one SECURE machine cannot masquerade as another SECURE machine. 

Relative to the TRUSTED machine table 266, theTRUSTED machine will recalculate the value of the product of 
the CPU-id times the hardware configuration checksum on each run in order to seed the random() (shown at step 1 ). 
Next, the TRUSTED machine 266 will call the random)) function by a total of (tv.vsecs/GCON) plus ACON times in 
order to generate the entire session key. 

Referring now to Fig. 6, there is yet another graphical and conceptual representation of key aspects of the invention 
which, in like manner to Fig. 5, may assist in their understanding. First, it will be recalled that it is necessary to obtain 
a hardware value associated with a machine which will thereafter be used as a seed to obtain random numbers which 
will comprise the session key. In the embodiment shown in Fig. 5, this collection of seeds was shown as a rectangular 

**5 plane 256 whose X and Y bounds were defined by the CPU-id and the hardware configuration checksum {LSCFG) 
although it has already been pointed out that the intention is not intended to be so limited to this particular form of 
arriving at differing seeds. 

Accordingly, in Fig. 6, this concept has been generalized at box 270, which will be seen to include metaphorically 
one or more prisms 272-276. Each such prism is intended to only conceptually represent a different scheme for arriving 

50 at some form of a hardware-dependent value which may be employed in tandem. It should thus be clear the invention 
is not intended to be limited to the manner of generating seeds shown in Fig. 5. The invention admits to virtually any 
procedure or series of procedures of any degree of complexity desired resulting in a seed value such as that represented 
by line 271 which may fall within a range of seed values such as that shown in the graph 278 of sufficient magnitude 
to thwart attempts to compromise the system (the range extending to 2,147,483,647 in the illustration of graph 278). 

55 Continuing with Fig. 6, lines 260 extending horizontally are seen which are intended to graphically illustrate a 

plurality of pseudo random output streams (such as those of bracket 260 in Fig. 5. Whereas the ordinant of graph 278 
represents possible seed values, the abscissa 281 measures the number of calls to the randomQ function, also cor- 
responding to a predetermined time divided by the familiar GCON constant and adjusted by ACON. A circle 282 is 
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shown in Fig. 6 (similar to the locks 264 in Fig. 5) which, has been blown up and shown on graph 283 having the seed 
value range as the ordinant 285 and the number of calls to random (in millions) in the abscissa, 287. The graph 290 
has as its Y axis 293 a range of actual seed values from graph 283 which are the actual results of calling random() 
and as its X axis 291 the seed number. From the foregoing it will be understood that key fragments 292-296 may 
thereby be generated. It will further be noted that for a complexity of 1, the key fragment 294 would be used as a 
session key. On the other hand, for complexities greater than 1, these key fragments 292-296 may be fed back as 
seeds into the method for selecting subsequent key fragments. 

It is of course desirable that upon each invocation of the masquerade protected tool for generating session keys 
that as detailed as possible hardware configuration information be gathered (as conceptually illustrated by the lenses 
of box 270, Fig. 6), and then mapped into the seed space of the pseudo random number generator as shown in graph 
278 of Fig. 6, e.g., the random() function ranging, in the described embodiment, from 0-2147483647. 

Table 1 which follows illustrates some actual representative key fragment numbers or random() results shown in 
the columns for differing numbers of calls to randomQ when randomQ has been seeded with the seeds shown in the 
lefthand column which differ in accordance with the particular unique hardware configuration number (such as HW#1 
shown in the column). It will be noted that results between result #2 through #10,000,010 have been omitted due 
obviously to the large number of columns required to show alt results. Also, it will be noted from Table 1 that 11 columns 
of results have been shown for results 10,000.000 through 10,000,010 corresponding to 11 locks previously described. 



TABLE 1 



SEEP 



HW #1 
HW #2 
HW #3 
HW #4 
HW #5 
HW #6 



0* 
1* 
2* 

845621309* 
1205769438* 
1973280456* 
2147483645* 
2147483646* 
2147483647* 



1990395451 
2078917053 
19955008 
877369427 
990647142 
269037359 
651088819 
739610422 
828132024 



1950343301 
143302914 
483746175 
1416513102 
1539379435 
1329309741 
929013518 
1269456779 
1509900040 



.10,000,010 

1467107738 
1753184651 
2039261564 
1393253895 
714551448 
622836706 
608876999 
894953912 
1181030825 



718222021 
920128997 
1122035973 
1426614629 
518764677 
1113596869 
112501093 
314408069 
51531504S 



1194136672 
1814331174 

287042027 
1195827568 
1027266981 
1974420396 

407294992 
1027489493 
1647683995 



1232915735 
460770759 

1836109331 
819239759 

1205211739 
75527097 

1401867215 
629722139 

2005060811 



623323901 
254862619 

2033884984 
325820421 

1296342674 
196978441 
654965925 
286504642 

2065527008 



992651780 

108788686 
1372409240 
1050195750 
35938096 

310492116 
1496757414 

612894320 
1876514874 



1555095128 
1850510617 
2145926107 
2096250483 
1493649445 
1007202948 
1742590483 
2038005973 
185937814 



1491367866 
318963580 
1294042941 
1631292630 
1244073863 
1805898726 
1787355254 
614950967 
1590030329 



150987678 
280583253 
410178829 

1138938711 
155297983 

1319031802 
835942775 
965538351 

1095133926 



2079171784 
8748332 
85808529 
2136697018 
1197237743 
1683511884 
774249370 
851309567 
928369763 



10,000,012 

135061501 
926162679 
1717263856 
2006998385 
1801108058 
232124393 
982983441 
1774084618 
417702148 



Turning now to Fig. 7, a graphic picture is provided of the sequence of steps for arriving at the session key 0 for 
complexity 1 (which is the session key), and the adjusted timestamp ("AT') and the corresponding "AT'TH random 
results from random() utilized to generate a session key for complexities greater than 1 . With respect to the TRUSTED 
machine, again it will be recalled that hardware specific information is utilized to determine which of the over 2 billion 
different pseudo random output streams (260 of Fig. 5 for example) will be employed in the initial part of the process. 

The confidential GCON and ACON constants it will be recalled affect how far down any pseudo random output 
stream the process goes to obtain a value. The "seed" 300 in Fig. 7 it will be recalled is the product of the CPU- 
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ID*hardware_checksum, and the timestamp will be recognized as the current time (conventionally the number of sec- 
onds past January 1 , 1 970) /GCON+ACON, abbreviated in Fig. 7 as "TS", 302. Also, the abbreviation CMPLX in Fig. 
7 will be recognized to be the familiar COMPLEXITY value constant. For a COMPLEXITY of 1, as previously noted, 
the ts 1 th randomQ result 304, in fact will be the session key. However, if more COMPLEXITY and thus security is 
5 desired, for complexities greater than 1 , an adjusted timestamp "AT", 306, is formulated, which is the previously de- 
scribed remainder of (timestamp-5)/10000. The seeds 308 are utilized for the downward randomQ streams, and the 
results of calling randomQ corresponding to the "AT" adjusted time (shown, generically, as "ZZZZZ" are the "AT"TH 
random results from calling randomQ after seeding the random number generator with each seed and are used to 
generate the session keys. 

10 Referring to the SECURE machine now, for a COMPLEXITY of 1, Table 2 shows the 11 calls to random() which 

could match the session key described with reference to Fig. 7, generated by the TRUSTED machine if the clocks are 
- in the same +/-5GCON range. Again, as per Fig. 7, the timestamp previously described is abbreviated as "TS" and the 
seed is the value from the table accessible by the secure machine which matches the IP address of the most recent 
inbound network connection. 

15 



TABLE 2 



0 s random ( s eed ) 

1 random ( ) 

2 random ( ) 
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For the SECURE machine in the case of a designated complexity greater than 1, Fig. 8 provides a graphical 
illustration of the conditions under which session keys could be matched and further shows that session keys for 

40 different time ranges share none of the same building blocks. In Fig. 8, TC refers to the clock time of the TRUSTED 
machine and "SC" refers to the clock time of the SECURE machine. From Fig. 8, it will be noted that if the clocks of 
the SECURE and TRUSTED machines are in the same GCON seconds range, then FFFFF will be the building blocks 
for both session keys. However, if the clocks are skewed within a predetermined range, the incoming session key will 
have been built by one of the following sets of building blocks: AAAAA, BBBBB, CCCCC, DDDDD, EEEEE, GGGGG, 

45 HHHHH, llllt, JJJJJ, or KKKKK. 

Finally, in order to better understand the invention, an actual example will be hereinafter provided of a user at- 
tempting to rlogin from a machine "crayon" to another machine *S410victim* employing masquerade protection. In the 
example, an illustration will first be provided wherein session keys do not match and access is denied, followed by a 
similar example wherein the keys match and access is granted. 

50 First, in accordance with the prior description, a masquerade-protected front end to rlogin will first detect that the 

S41 Ovictim is listed in the /etc/hosts. SECURE file, whereupon it collects the previously described CPU-id and checksum 
of the configuration of the machine currently executing the front end. In the example, the CPU-id will (arbitrarily) be 
assumed to be 193, and the checksum of LSCFG-V will assumed to be 625. The front end, upon multiplying these 
numbers together, obtains a seed value of 1 20625 which obviously will be hardware-specific. 

55 The front end thereafter calls the routine gettimeofday() in order to determine how many seconds have passed 

since midnight, January 1, 1970. In the example which follows, this function was called on Tuesday, June 27th at 10: 
35 a.m. CDT, 1995. 

The "seconds" value returned by this call to gettimeofday is then divided as previously described by the constant 
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GCON and added to the constant ACON (both, it will be recalled being secret to all -crayon" machine users except for 
the root user). This is done in order to obtain a value for the "timestamp" variable which depends not only on the date 
and time, but also the secret values of GCON and ACON previously decided upon by the crayon machine's adminis- 
trator. The results will be as follows: 

gettimeofdayO returned 804267329 

gettimeofday return + GCON of 37 results in 21736954 

ACON of -21 473251 is added to the dividend to obtain a timestamp value of 263703 

The front end to rtogin will then call srandom(1 20625) (where 1 20625 is the hardware-dependent first seed value 
described above) in order to seed the random number generator. 

The random() function is then called "timestamp-2" times, discarding the results generated therefrom which are 
shown as follows in Table 3: 



TABLE 3 HERE 





result from random () 
rasult from random () 


call 
call 


1 was 

2 was 


472515509 
1S88900722 




rasult from random () 


call 


3 was 


915019139 




rasult from random () 


call 


4 was 


1760430670 




rasult from random () 


call 


5 was 


519503375 


25 


result from random () 
rasult from random 0 


call 
call 


S was 
7 was 


556921145 
1823984006 


result from random () 


call 


a was 


1347300635 




result from random t) 


call 


9 was 


500795831 




result from random () 


call 


10 was 


702644326 


30 


rasult from random O 


call 


11 was 


769281827 




rasult from random {) 
result from random () 


call 
call 


12 was 

13 was 


887862883 
1851855625 




rasult from random () 


call 


14 was 


1292778304 


35 


result from random () 
263,679 linos of 


call 15 was 1423281335 
random numbers delated. . . 




result from random {) 
result from random () 


call 
call 


263695 was 

263696 was 


690517059 
2005013007 




result from random t) 


call 


263697 was 


518938856 


40 


rasult from random 0 


call 


263699 was 


683953746 




result from random {) 


call 


263699 was 


2009848507 




result from random () 


call 


263700 was 


535088599 




result from random () 


call 


263701 was 


729576118 



45 



SO 



Random() is then called COMPLEXITY times (having a value of 4 in this example and known only to crayon's 
system administrator), with the results being retained as seeds as shown in Table 4: 



TABLE 4 









====== 




result 


from 


random () 


call 


263702 


was 


result 


from 


random () 


call 


263703 


was 


result 


from 


random () 


call 


263704 


was 


result 


from 


random {} 


call 


263705 


was 






, = 3X=SSSSSI =! = ==== = =" 



109512711 Assign to seedtl] 

877852427 Assign to seed [2] 

292077057 Assign to seadO) 

761158949 Assign to seed[4) 
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Next, after dividing the timestamp value of 263703 by 10000, the remainder thereof, which is 3703, is utilized 
wherein random() is called 3703 times in order to generate fragments of session_key (wherein session_key is initialized 
to null). The results are shown in Table 5 resulting in the session_key shown at the end of the table. The front end to 
rfogin then prepends the TERM variable, which was "aixterm" with the session key shown at the bottom' of Table 5 in 
order to create a new TERM variable of session_key:aixterm. 



TABLE 5 



10 



15 



20 



25 



30 



35 



40 



seed[l] = 109512711 

result from random () call 

result from random () call 

result froa random () call 

result from random {) call 

result from random () call 



1 was 1111472344 

2 was 1211753596 

3 was 1405547944 

4 was 191533680 

5 was 1853352561 



.3,679 linos of random numbers deleted... 



result from random () call 
result from random () call 
result from random {) call 
result from random () call 
139933611 / 2.147483648 Is 
after appending fragment, 

seed (2] = 877852427 

result from random () call 

result from random () call 

result from random () call 

result from random () call 

result from random () call 



3700 was 1701522600 

3701 was 336348948 

3702 was 151550372 

3703 was 139933511 
(key fragment) 65161667 

session _Jcey is 65161667 



was 23395926 
was 2134425828 
was 1092895110 
was 81559368 
was 1299968701 



...3,67 9 lines of random numbers deleted. 



result from random () call 
result from random () call 
result from random () call 
result from random {) call 
911460651 / 2.147483648 is 
after appending fragment 



3700 was 19949398 

3701 was 1982066460 

3702 was 605740292 

3703 was 911460651 
(key fragment) 424431949 

session_Jcey is 65161667424431949 



seedt3J - 292077057 
result from random {) call 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
... .3, 679 Unas of random 
result from random {) call 
result from random {) call 
result from random () call 
result from random () call 
86314347 / 2.147483648 is 
after appending fragment, 

seed [4) = 761158949 

result from random () call 

result from random £) call 

result from random () call 

result from random () call 

result from random () call 



was 1385733309 



was 53438210 
was 93864347 
was 19577S5326 
was 1339349387 
numbers deleted. . . 

3700 was 1007066211 

3701 was 673137672 

3702 was 1591210132 

3703 was 86314347 
(key fragment) 40193248 

session_key is 6516166742443194940193248 



1 was 912623767 

2 was 836836246 

3 was 1995051113 

4 was 795444970 

5 was 1863667243 



45 



...3,679 lines of random numbers deleted. 



result from random 0 call 
result from random () call 
result from random () call 
result from random () call 
1476078315 J 2.147483648 is 



3700 was 527380609 

3701 was 1S70633728 

3702 was 1059892980 

3703 was 1476078315 
(key fragment) 687352538 



after appending fragment, sessionjcey is S516166742443194940193248687352538 



sassion_kay is: 6516166742443194940193248687352538 



Then the normal (e.g., original) rlogin command is utilized, which transfers the terminal type as part of its normal 
operation, in order to connect to the S410victim as follows: 
crayon_rlogin — > (standard rfogin interface) — > s410 victim Jogin 

On the S41 Ovictim machine, a masquerade-protected version of the "login" function reads the terminal type passed 
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in from the crayon machine, and splits it at the colon, in order to read the incoming <session key> shown in Table 5. 
The terminal type is then set to its original value of -aixterm'. The S410victim machine uses the "netstaf in order to 
view the IP address of the machine which has most recently started a connection over the network (in the example 
1 29 35 1 28 1 1 3) It also utilizes the "hosf command to convert it to a hostname: crayon.austin.ibm.com. The machine 
then will look up this hostname -crayon.austin.ibm.com" in the /etc/security/masqproUist table in which the following 
line will be located: 

crayon.austin.ibm.com is 129.35.128.113 4 120625 37 -21473251 

From this line, the S4iOvictim machine may determine the crayon's constants, namely 



COMPLEXITY value: 


4 


seed value: 


120625 


GCON value: 


37 


ACON value: 


-21473251 



The "login front end' then calls the gettimeofday() function to determine how many seconds have passed since 
midnight, January 1 , 1 970. It then begins calculating what the incoming session key should be for multiple times cen- 
tered around the present time, stopping if the incoming key matches the current calculated key. It w.ll be recalled that 
the "valid time range" concept is necessary to compensate for clock skew and/or clock drift between system clocks on 
the two machines. 

The predetermined number of multiple times is shown as follows in table 6: 









TABLE 


6 












now 




(5* 


GCON) 


seconds , 


now 




(4* 


GCON) 


seconds , 


now 




(3* 


GCON) 


seconds , 


now 




(2* 

( 


GCON) 


seconds , 


now 




GCON) 


seconds , 


now, 








seconds , 


now 


+ 


t 


GCON) 


now 




(2* 


GCON) 


seconds, 


now 


+ 


(3* 


GCON) 


seconds , 


now 




(4* 


GCON) 


seconds, and 


now 


■t- 


(5* 


GCON) 


seconds . 



If it is assumed that the gettimeofday() function returned a function 804267298, then this result divided by the 
GCON constant of 37 yields 21736954. Adding the ACON value of -21473251 to this result yields a timestamp value 
of 263703. 

The srandom(1 20625) function will then be called to seed the random number generator. 



16 



EP 0 768 595 A1 



10 



15 



20 











TABLE 


7 


S3S3BI03SS==: 


S3333333 33 33333 3 


333333= 




:===3saasaa: 


result 


from 


random ( ) 


call 




was 


472515509 


result 


from 


random ( ) 


call 


2 


was 


1588900722 


rasult 


from 


random ( ) 


call 


3 


was 


915019139 


result 


from 


randoa ( ) 


call 


4 


was 


1750430570 


result 


from 


randoa ( ) 


call 


5 


was 


519503375 


result 


from 


ran don ( ) 


call 


5 


was 


556921145 


result 


from 


random ( ) 


call 


7 


was 


1823984006 


result 


from 


random { ) 


call 


S 


was 


1347300635 


result 


from 


random ( j 


call 


9 


was 


500795831 


result 


from 


random ( ) 


call 


10 


was 


702644326 


result 


from 


random ( ) 


call 


11 


was 


759281827 


result 


from 


randoa ( ) 


call 


12 


was 


887862883 


result 


from 


random { ) 


call 


13 


was 


1851355625 


result 


from 


random ( ) 


call 


14 


was 


1292778304 


result 


from 


random { ) 


call 


15 


was 


1423281335 


263, S79 


linos of 


random numbers deleted. . . 


result 


from 


random ( ) 


call 


263695 


was 


690517059 


result 


from 


random ( ) 


call 


253695 


was 


2005013007 



then call random () 


( 11 -(-COMPLEXITY ) 


times , saving the 


results as seeds. 




Will use 




























seeds 


o. 


1* 


2, 


and 


3 


to 


create 


session 


key 


check 


for 


now (5*GCON) 


seconds , 


seeds 


1, 


2, 


3, 


and 


4 


to 


create 


session 


key 


check 


for 


now- (4*CC0N) 


seconds , 


s a ads 


2, 


3, 


4, 


and 


5 


to 


create 


session 


key 


check 


for 


now- (3*GC0N) 


seconds , 


seeds 


3, 


4, 


5, 


and 


6 


to 


create 


session 


key 


check 


for 


now- (2*GCON) 


seconds , 


seeds 


4, 


5, 


6, 


and 


7 


to 


create 


session 


key 


check 


for 


now- { GCON) 


seconds , 


seeds 


5, 


s, 


7, 


and 


a 


to 


create 


session 


*.y 


check 


for 


now. 




seedB 


6, 


7, 


8, 


and 


9 


to 


create 


session 


key 


check 


for 


now+ ( gcon) 


seconds, 


seeds 


7, 


8, 


9, 


and 


10 


to 


create 


session 


key 


check 


for 


now+ (2*GC0N) 


seconds. 


seeds 


8, 


9 , 


10, 


and 


11 


to 


create 


session 


key 


check 


for 


nov+ (3*GC0N) 


seconds , 


seeds 


9, 


10,11, 


and 


12 


to 


create 


session 


key 


check 


for 


now+(4*GC0N) 


seconds , 


seeds 


10, 


11. 


12, 


and 


13 


to 


create 


session 


key 


check 


for 


now+(5*GCON) 


seconds. 



25 



result from random () call 

result from random () call 

result from random () call 

result from random {) call 



263697 was 518338656 Assion to seed [0 J 

263698 was 633953746 Assign to se«d[l) 

263699 was 2009848507 Assign to seed [2) 

263700 was 535088599 Assign to seed [3] 



30 



35 



40 



result 
result 
result 
result 
result 
result 
result 
result 
result 
result 
result 



from 
from 
from 
from 
from 
from 
from 
£rom 
from 
from 
from 



random ( ) 
random ( ) 
random ( ) 
random ( ) 
random () 
random ( ) 
random () 
random () 
random ( ) 
random ( ) 
random ( ) 



call 
call 
call 
call 
call 
call 
call 
call 
call 
call 
call 



263701 
263702 
263703 
263704 
263705 
263706 
253707 
263708 
263709 
263710 
263711 



was 
was 
was 
was 
was 
was 
was 
was 
was 
was 
was 



729576118 
109512711 
877852427 
292077057 
761158949 
898090332 
1328262702 
1700051705 
1049723143 
1977441982 
360217799 



Assign 

Assign 

Assign 

Assign 

Assign 

Assign' 

Assign 

Assign 

Assign 

Assign 

Assign 



to seed [4] 
to seed [5] 
to seed [5] 
to seed [7] 
to seed [8] 
to seed [9] 
to seed £10] 
to seed [11] 
to seed{12] 
to seed [13] 
to seed [14] 



=3333==== 



With a timestamp of 263703, the remainder of timestamp after being divided by 10000 is 3703. 

The session_key is then initialized to null, and different length random() strings are utilized for each session key. 

For a session_key # of 0, wherein the timestamp is 263703, this timestamp -5 is 263698 which, after adding the 
aforementioned session key # of 0, still results in 263698. The remainder of this 263698 value, after dividing by 10000 
is 3698. 

This value of 3698 is then used in order to call random() 3698 times in order to generate fragments of session_key 
[0] as shown in Table 8: 



55 
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TABLE 8 



70 



75 



20 



2S 



seed[0l = 518838856 
roeult from random () 
result from random () 
result from random O 
result from random 0 
rasult from random 0 

3,67 9 lines of random 

result from random 0 call 
result from random 0 
result from random {} 
result from random () 
476900761 / 2.147483648 i 
after appending fragment, 



call 
call 
call 
call 
call 



call 
call 
call 



1 was 1434641391 

2 was 1785492909 

3 was 247519584 

4 was 430401955 

5 was 302823428 
numbers deleted. . . 

3695 was 688574576 

3696 was 1592424908 

3697 was 314425712 

3698 was 476900761 

j (key fragment) 222074225 
session_key ia 222074225 



seedtl] 3 683953746 
result from random () call 
result from random () call 
result from random () call 
result from random 0 call 
result from random () call 

3,679 lines of random 

result from random () call 
result from random () call 
result from random t) call 
result from random () call 
1597503509 / 2.147483648 
after appending fragment 

seed [21 - 2009848507 
result from random () 
result from random () 
result from random () 
result from random () 



1 was 676780296 

2 was 579575439 

3 was 16909259 

4 was 997224993 

5 was 733048898 
numbers deleted. . . 

3695 was 1597753697 

3696 was 1724422159 

3697 was 1902719308 

3698 was 1597503509 

is (key fragment) 74389SS30 
session_)cay is 222074225743895530 



call 
call 
call 
call 



1 
2 
3 
4 

result from random () call 5 
....3,679 lines of random numbers 
result from random {) call 369 5 
result from random () call 3696 
result from randomO call 3697 



was 
was 
was 
was 
was 
deli 
was 
was 
was 



1727438734 
753135060 
1692929070 
532384076 
2057764045 
»ted. . . 
1606094916 
2048751823 
1560585170 



30 



3B 



40 



45 



result from randomO call 3698 was 818799147 
813799147 / 2 147483643 is (key fragment) 381283074 

after appending fragment, session.key is 22207422574389 5530381283074 



seed [3] = 535088599 
result from randomO call 
result from random U call 
result from randomO call 
result from random t) call 
result from randomO call 



1 was 1458307412 

2 was 1837081216 

3 was 1719654976 

4 was 2083499744 

5 was 428709089 



..3,679 lines of random numbers deleted 



result from randomO call 
result from randomO call 
result from randomO call 
result from randomO call 
1800572499 / 2.147483648 is 



3695 was 42425754 

3696 was 1625346673 

3697 was 573973050 

3698 was 1800572499 
<koy fragment) 838456928 



after appending fragment, sessionjcey is 222074225743895530381283074838456928 
sessionJceyCO] : 222074225743895530381283074838456928 

does not match: 651S165742443194940193248687352538 the incoming key. 



As also shown at the end of Table 8 : the session_key[0] does not match the incoming key. 

Again, the session_key is initialized to null, and different length randomf) streams are utilized for each session 
key, with the session key # now being 1 . 
55 Similarly to previously, with a timestamp of 263703, this value -5 is 263698, which after adding the session key 

"1" becomes 263699. 

The remainder of 263699. after dividing by 10000 is 3699. 

The random() function is then called 3699 times in order to generate fragments for session_key[1] as shown in 
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TABLE 9 



seed[l] = 633953746 

result from random 0 call 1 was 67 67 802 96 

result from random 0 call 2 was 579575439 

result from random () call 3 was 16909259 

result from random () call 4 was 997224993 

result from random () call 5 was 733046898 

1® ....3,679 lines of random numbers deleted... 

result from random () call 3696 was 1734422159 

result from random O call 3(97 was 1902719308 

result from random O call 3698 was 1597503509 

result from random () call 3699 was 812713069 
812713069 / 2.147483648 is (key fragment) 378449022 

after appending fragment, 9es0ian_key is 378449022 

75 seed (2] =* 2009848507 

result from random () call 1 was 1727438734 

result from random ( ) call 2 was 7 5313 5060 

result from random {) call 3 was 1692929070 

result from random 0 call 4 was 532384076 

result from random O call 5 was 2057764045 

....3,67 9 lines of random numbers deleted... 

20 result from random () call 3696 was 2048751823 

result from random <) call 3697 was 1560585170 

result from random!) call 3698 was 818799147 

result from random () call 369 9 was 841898830 
841898830 / 2.147483648 is (key fragment) 39203968S 

after appending fragment, sesslon_Jcay is 37844902239203 9686 



aeed(3] = 535068599 

result from random () call 1 was 1458307412 

result from random!) call 2 was 1837081216 

result from random () call 3 was 1719654976 

result from random 0 call 4 was 208349 9744 

result from random () call 5 was 428709089 

....3,67 9 lines of random numbers deleted... 
result from random 0 call 3696 was 1625346673 
30 result from random!) call 3697 was 573973050 

result from random!) call 3698 was 1800572499 
result from random () call 369 9 was 276142892 
276142892 / 2.147463648 is (key fragment) 128589049 

after appending fragment, session_key is 378449022392039686128589048 
seed [4] =* 729576118 

result from random!) call 1 was 19 65191682 

35 result from random!) call 2 was 1722311523 

result from random!) call 3 was 1326087673 

result from random!) call 4 was 689429261 

result from random!) call 5 was 1464874670 

....3, 679 lines of random numbers deleted^-.. 

result from random () call 3696 was 1007954093 

result from randomt) call 3697 was 958461924 
4Q result from random!) call 3698 was 125929709 

result from random!) call 3699 was 2002160207 

2002160207 / 2.147483648 is (key fragment) 932328522 

after appending fragment, session Jcey is 378844902239203968612858889000048932328522 
9esslon_key[l] : 378449022392039686128589048932328522 

does not match: 6516166742443194940193248687352538 the incoming key 



Again, at the end of Table 9, the session_key[1] does not match the incoming key. 

Continuing with the example, with a remainder of 3700, calling random() 3700 times, to generate fragments of 
session_key(2] , as shown in Table 10, results in the session_key[2] which does not match the incoming key. Similarly, 
so calling random() 3700 times to generate fragments of session_key[3] results in the session_key[3] in the manner shown 
in Table 11 which also does not match the incoming key. 
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TABLE 10 



seed(2] » 2009848507 
rasult from random (} call 
result from random () call 
rasult from random () call 
rasult from random {) call 
result from random () call 
.... 3 , 679 lines of random 
result from random {) call 
result from random () call 
result from random {) call 
result from random () call 
757516734 / 2.147483648 i! 
after appending fragment, 



was 1727438734 
was 753135060 
1692929070 
532384076 
2057764045 



was 
was 
was 

numbers deleted. . . 

3697 was 1560585170 

3698 was 818799147 

3699 was 841898830 

3700 was 757516734 

i (key fragment) 352746218 
session_)cey is 352746218 



seed(3] = 535088599 

result from random () call 

result from random { } call 

result from random () call 

result from random {) call 

result from random () call 



1 was 1458307412 

2 was 1837081216 

3 was 1719654976 

4 was 2083499744 

5 was 428709089 



....3,679 lines of random numbers deleted 
result from random () call 
result from random () call 
result from random () call 
result from randomO call 
1746184064 / 2.147483648 is 



3697 was 573973050 

3698 was 1800572499 

3699 was 276142892 

3700 was 1746184064 
(key fragment) 813130319 



after appending fragment, sassion_Jcay is 352746218813130319 



seed[4j = 729576118 
result from random {) call 1 
result from random () call 2 
result from random () call 3 
result from random () call 4 
result from random () call 5 
....3,679 lines of random numbers 
rasult from random () call 
result from random () call 
result from random () call 
result from random () call 
2128166917 / 2.147483648 is 



3697 
3698 
3699 
3700 



1965191682 
1722311523 
1326087673 
689429261 
1464874670 
deleted. . . 
was 958461924 
was 125929709 
was 2002160207 
was 2128166917 



was 
was 
was 
was 
was 



(key fragment) 991004943 



arter appending fragment, session_key is 352746218813130319991004943 



seed(5] = 109512711 

result from random () call 

result from random 0 call 

result from random () call 

result from random 0 call 

result from random () call 



..3,579 lines of random numbers 
result from random () call 
result from random () call 
result from random 0 call 
result from random {) call 
1701522600 / 2.147483648 is 



was 1111472844 
was 1211763696 
was 1405547944 
was 191533680 
was 1853352561 
deleted. . - 

3697 was 208480858 

3698 was 1813571955 

3699 was 1705903748 

3700 was 1701522600 
(key fragment) 792333185 



".ZllnJITu ^S»4»l.«31303X»tl.04M37.23331« 

session Jcey [2] : 352746218813130319991004943792333185 
does not match: 6516166742443194940193248687352538^^ 



With a remainder of 3701 and a call random(3701 ) results in session_key[3] which does not match the incoming key 
as shown in Table 11: 
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TABLE 11 



10 



15 



20 



seed[3) = 535088599 
result from random {) call 
result from random () call 
result from random () call 
result from random {) call 
result from random () call 
....3,679 lines of random 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
1104894544 / 2.147483648 
after appending f r agmen t 



1 was 1458307412 

2 was 1837081216 

3 was 1719654976 

4 was 2083499744 

5 was 428709089 
numbers deleted. . . 

3696 was 1800572499 

3699 was 276142892 

3700 was 1746184064 

3701 was 1104894644 

is (key fragment) 514506638 
session^ Jcey Is 514506638 



sead[4] = 729576118 
result from random <) call 
result from random {) call 
result from random {) call 
result from random 0 call 
result from random () call 
....3,67 9 lines of random 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
1964392946 / 2.147483648 i 
after appending fragment. 



1 was 1965191682 

2 was 1722311523 

3 was 1326087673 

4 was 689429261 

5 was 1464874670 
numbers deleted. . . 

3698 was 125929709 

3699 was 2002160207 

3700 was 2128166917 

3701 was 1964392946 
a (key fragment) 914741754 
sesslon_Jcey is 514506638914741754 



25 



30 



35 



40 



seedtS] = 109512711 
result from random 0 call 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
....3,679 lines of random numbers 
result from random 0 call 
result from random () call 
result from random () call 
result from random () call 
336348948 / 2.147483648 is 
after appending fragment. 



1 was 1111472844 

2 was 1211763696 

3 was 1405547944 

4 was 191533680 

5 was 1853352561 
deleted. . . 

3698 was 1813571955 

3699 was 1705903748 

3700 was 1701522600 

3701 was 336348948 
(Kay fragment) 156624689 

aesaian_key is 514506638914741754156624689 



seed [6] =» 877852427 

result from random () call 

result from random () call 

result from random <) call 

result from random () call 

result from random () call 



1 was 23395926 

2 was 2134425328 

3 was 1092895110 

4 was 81559868 

5 was 1299968701 



.3,679 lines of random numbers deleted., 



result from random () call 
result from random () call 
result from random () call 
result from random () call 
1982066460 / 2.147483648 is 



3698 was 1902157323 

3699 was 2134640950 

3700 waa 19949398 

3701 was 1982066460 
(key fragment) 922971606 



after appending fragment, seseionjcey is 514506638914741754156624689922971606 
session_Jcey [3] : 514506638914741754156624689922971606 



does not match: 6516166742443194940193248687352538 



the incoming key. 



Continuing this process with a call to random() 3702 times, results in session_key[4] which does not match the 
incoming key, as shown in Table 12: 



so 
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TABLE 12 



15 



20 



25 



30 



35 



seed[4] = 729576118 
result from randonO call 
result from random () call 
result from random {) call 
result from random (J call 
result from random () call 
....3,679 lines of random 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
1028286332 / 2.147483648 
after appending fragment 



was 1965191682 
was 1722311523 
1326087673 
689429261 
1464874670 



was 
was 
was 

numbers deleted. - . 

3699 was 2002160207 

3700 was 2128166917 

3701 was 1964392946 

3702 was 1028288332 
is (key fragment) 478834062 



session_key is 478834062 



seed (51 = 109512711 
result from random () call 
result from random () call 
result from random t) call 
result from random {) call 
result from random () call 
....3,679 lines of random 
result from random () call 
result from random () call 
result from random () call 
result from random {) call 
151550372 / 2.147483648 i 
after appending fragment, 

seed [6] = 877852427 

result from random () call 

result from random () call 

result from random () call 

result from random { ) call 

result from random 0 call 



U J.J.UUk fcUlUWWtl w«.fc— — 

..3,679 lines of random numbers deleted 



1 was 1111472844 

2 Was 1211763696 

3 was 1405547944 

4 was 191533680 

5 was 1853352561 
numbers deleted. . . 

3699 was 1705903748 

3700 was 1701522600 

3701 was 336348948 

3702 was 151550372 
s (key fragment) 70571139 

sessionjeey is 47883406270571139 



1 was 23395926 

2 was 2134425828 

3 was 1092895110 

4 was 81559868 

5 was 1299968701 



result from random () call 
result from random () call 
result from random (> call 
result from random () call 
60*574029 2 / 2 .147483648 is 



3699 was 2134640950 

3700 was 19949398 

3701 was 1982066460 

3702 was 605740292 
(key fragment) 282069802 



605740292 / 2.j,474aJb40 as VJt«y ttayunmw 

after appending fragment, sessionjeey is 47883406270571139282069802 



saed[7) » 292077057 

result from random {) call 1 

result from random () call 2 

result from random () call 3 

result from random O call 4 

result from random () call 5 
....3,679 lines of random numbers 

result from random () call 3699 

result from random () call 37 00 

result from random <) call 37 01 

result from random () call 3702 



1385733309 
53438210 
93864347 
1957755326 
1339349887 
deleted. . . 
was 1067583161 
was 1007066211 
was 673137672 
was 1591210132 



was 
was 
was 
was 
was 



1591210132 / 2.147483648 is (key fragment) 740964949 
after appending fragment, sessionjeey is 47883406270571139282069802740964949 

session_key(4] : 47 883406270571139282069802740964949 

does not match: 6516166742443194940193248687352538 the iacomlng_key . _ 



SS3fi3S3S3 



45 



However, with respect to Table 13, calling random() 3703 times generates a session_key[5] which, as desired, 
finally matches the incoming key. 



50 
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TABLE 13 



aeedCS] - 109512711 
result from random (> call 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
....3,67 9 lines of random 
result from random {) call 
result from random () call 
result from random () call 
result from random () call 
139933611 / 2.147483643 ifl 
after appending fragment, 

3994(6] = 877852427 

result from random () call 

result from random {) call 

result from random () call 

result from random () call 

result from random () call 
— .3,679 lines of random numbers 



was 1111472844 
was 1211763696 
1405547944 
191533680 
1853352561 



was 
was 
was 

numbers deleted. . . 

3700 was 1701522600 

3701 was 336348948 

3702 was 151550372 

3703 was 139933611 
i (Key fragment) 65161667 
seosion_Jcey is 65161667 



result from random {) call 
result from random () call 
result from random {) call 
result from random {) call 
911460651 / 2.147483648 is 



3700 
3701 
3702 
3703 



was 23395926 
was 2134425828 
was 1092895110 
was 81559868 
was 1299966701 
delated. . . 
was 19949398 
was 1982066460 
was 605740292 
was 911460651 



(key fragment) 424431949 



after appending fragment, seaslon_key is 65161667424431949 



seed [7] = 292077057 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
result from random () call 
....3,67 9 lines of random 
result from random {) call 
result from random!) call 
result from random {) call 
result from random {) call 
86314347 / 2.147483648 is 
after appending fragment. 



1385733309 
53438210 
93864347 
1957755326 
1339349887 



was 
was 
was 
was 
was 

numbers deleted. . . 

3700 was 1007066211 

3701 was 673137672 

3702 was 1591210132 

3703 was 86314347 

(Key fragment) 40193248 

sesslon^Xey is 6516166742443194940193248 



seed(83 - 761158949 

result from random () call 1 was 912623767 

result from random () call 2 was 83 6836246 

result from random () call 3 was 1995051113 

result from random () call 4 was 79 544497 0 

result from random () call 5 was 1863667 243 

....3,679 lines of random numbers deleted.. 



3700 was 527380609 

3701 was 1670683728 

3702 was 1059892980 

3703 was 1476078315 
1476078315 / 2.147483648 is (key fragment) 687352538 

after appending fragment, session^Jcey is 6516166742443194940193248687352538 



result from random () call 

result from random () call 

result from random () call 

result from random {) call 



sesalon_Jcey (5] £ 6516166742443194940193248667352538 
EXACTLY HATCHES: 651616674244319494019324868735253 8 



the incoming Jcay! 



SO 



55 



Next, the S410victim machine will scan the A/a r/tmp/masq keys file to see if the resulting key from Table 13 has 
been used before. If it has been, the S410victim machine would deny access. However, this check of the file indicates 
the key has not yet been utilized. Accordingly, the S410victim machine will then append this key and a timestamp to / 
var/tmp/masq keys, used as follows: 

651616666742443194940193248687352538 Tue_Jun_27_10:35:20_CDT_1995, and thereafter grants the desired 
access. 

While the invention has been shown and described with reference to particular embodiments thereof, it will be 
understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein 
without departing from the spirit and scope of the invention. 
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Claims 

(l7) A method for providing masquerade protection in a computer network, comprising: 

5 generating a session key with a first machine as a function of a timestamp and one or more hardware char- 

acteristics unique to said first machine; 

transmitting said session key over said network from said first machine to said second machine; 
generating a plurality of locks with said second machine as a function of said timestamp and said hardware 
characteristics; 

70 testing with said second machine whether said session key matches one of said plurality of locks; and 

granting access from said first machine to said second machine when said session key matches said one of 
said plurality of locks. 

2. The method of Claim 1 , wherein said session key is valid for a predetermined time functionally related to said 
is timestamp. 

3. The method of Claim 1 or Claim 2, wherein said hardware characteristics include a central processing unit iden- 
tification number associated with a central processor unit in said first machine. 

20 4. The method of any one of Claims 1 to 3, wherein said hardware characteristics include a checksum determined 
from multiple hardware aspects of said first machine. 

5. The method of Claim 4 wherein said session key is a function of a product of a central processor unit identification 
number of said first machine and said checksum. 



25 



50 



6. The method of any preceding claim, further including 



maintaining with said second machine a list of previously used session keys; and wherein said method further 
includes 

30 testing whether said session key is on said list, and, if so. inhibiting said testing of whether said session key 

matches said one of said plurality of locks, and denying access. 

7. The method of Ctaim 1 further including 

seeding a pseudo random number generator function with a number corresponding to said one or more 
35 hardware characteristics; and wherein said session key is generated from a number generated from said seeded 

pseudo random number generator function. 

8. The method of Claim 7 including 

specifying at said first and second machines a COMPLEXITY number corresponding to a desired level of 
40 said masquerade protection; and wherein said pseudo random number generator function is seeded a number of 

times corresponding to said complexity number. 

9. The method of any preceding Claim, further including 

45 maintaining on said second machine a list of machines on said network whcih have said masquerade protection 

and may be granted access to said second machine; 

wherein said transmitting occurs at a time corresponding to a timestamp generated with said first machine; and 
wherein said list includes a network address, and information for generating said time with said second ma- 
chine. 



10. The method of Claim 9 further including 



maintaining on said first machine a list of machines on said network to which said first machine will permit said 
session keys to be sent; and 

S5 preventing said transmitting of said session key to said second machine when said second machine is not on 

said list on said first machine. 

1 v) An apparatus for providing masquerade protection in a computer network, comprising: 
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means for generating a session key with a first machine as a function of a timestamp and one or more hardware 
characteristics unique to said first machine; 

means for transmitting said session key over said network from said first machine to said second machine; 
means for generating a plurality of locks with said second machine as a function of said timestamp and said 
hardware characteristics; 

means for testing with said second machine whether said session key matches one of said plurality of locks; 
and 

means for granting access from said first machine to said second machine when said session key matches 
said one of said plurality of locks. 

2.. The apparatus of Claim 11 further including 

means for seeding a pseudo random number generator function with a number corresponding to said one 
or more hardware characteristics; and wherein said session key is generated from a number generated from said 
seeded pseudo random number generator function. 

3. The apparatus of Claim 11 or Claim 12, further including 

means for maintaining with said second machine a list of previously used said session keys; and wherein said 
apparatus further includes 

means for testing whether said session key is on said list, and, if so, inhibiting said testing of whether said 
session key matches said one of said plurality of locks, and denying access. 

4. The apparatus of Claim 12 including 

means for specifying at said first and second machines a COMPLEXITY number corresponding to a desired 
level of said masquerade protection; and" wherein said pseudo random number generator function is seeded a 
number of times corresponding to said complexity number. 
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SECURE GETS SESSION KEY FROM 
TERM VARIABLE, RESTORES TERM 
VARIABLE TO VALID VALUE 



T 



execute rlogind using netstat 

COMMANDS TO DETERMINE IP ADDRESS 



T 



DETERMINE GCON, ACON, COMPLEXITY 
FROM LOOKUP TABLE 
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RANDOM STREAM OF 
ONE-TIME USE PADS 
GENERATED WITH SEEDS 
AND RANDOM ( ) 



9,999 
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258 
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